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Abstract 


This document specifies the Deterministic Networking data plane when encapsulating IP over an 
MPLS packet-switched network. 
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1. Introduction 


Deterministic Networking (DetNet) is a service that can be offered by a network to DetNet flows. 
DetNet provides a capability for the delivery of data flows with extremely low packet loss rates 
and bounded end-to-end delivery latency. General background and concepts of DetNet can be 
found in the DetNet architecture [RFC8655]. 
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This document specifies use of the IP DetNet encapsulation over an MPLS network. It maps the IP 
data plane encapsulation described in [RFC8939] to the DetNet MPLS data plane defined in 
[RFC8964]. 


2. Terminology 


2.1. Terms Used in This Document 


This document uses the terminology and concepts established in the DetNet architecture 
[RFC8655] and in [RFC8938]. The reader is assumed to be familiar with these documents and their 
terminology. 


2.2. Abbreviations 


This document uses the abbreviations defined in the DetNet architecture [RFC8655] and in 
[RFC8938]. This document uses the following abbreviations: 


CE Customer Edge (equipment) 

d-CW DetNet Control Word 

DetNet Deterministic Networking 

DF DetNet Flow 

DN DetNet 

L2 Layer 2 

LSP Label-Switched Path 

MPLS Multiprotocol Label Switching 

PEF Packet Elimination Function 

PRF Packet Replication Function 

PREOF Packet Replication, Elimination, and Ordering Functions 
POF Packet Ordering Function 

PW Pseudowire 

S-Label DetNet "service" Label 

S-PE Switching Provider Edge 

T-PE Terminating Provider Edge 

TE Traffic Engineering 

TSN Time-Sensitive Networking; TSN is a Task Group of the IEEE 802.1 Working Group 
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2.3. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 
interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


3. DetNet IP Data Plane Overview 


Figure 1 illustrates an IP DetNet with an MPLS-based DetNet network as a sub-network between 
the relay nodes. An IP flowis mapped to one or more PWs and MPLS (TE) LSPs. The end systems 
still originate IP-encapsulated traffic, identified as DetNet flows. The relay nodes follow 
procedures defined in Section 4to map each DetNet flow to MPLS LSPs. While not shown, relay 
nodes can provide service sub-layer functions such as PREOF using DetNet over MPLS, and this is 
indicated by the solid line for the MPLS-facing portion of the Service component. Note that the 
Transit node is MPLS (TE) LSP aware and performs switching based on MPLS labels; it need not 
have any specific knowledge of the DetNet service or the corresponding DetNet flow 
identification. See Section 4 for details on the mapping of IP flows to MPLS, and [RFC8964] for 
general support of DetNet services using MPLS. 


DetNet IP Relay Transit Relay DetNet IP 
End System Node Node Node End System 
+---------- + +---------- + 

| Appl EEG End to End Service ---------- >| Appl 
+---------- S eaea + +-----..... +---------- + 
| Service |<--: Service |--DetNet flow ---| Service :-->| Service | 
| | ; |<-DN MPLS flow ->| ; | 
+---------- + +--------- + +---------- + +--------- + +---------- + 
| Forwarding | |Fwd| |Fwd| |Forwarding| |Fwd| | Fwd} | Forwarding | 
+------- .==+ +-.-+ +-.-+ +----.---.-+ +-.-+ +-.-+ +---.------ + 
Link : | ae a SN INKE: SEERE 2 N 
ee + +-[ Sub ]-+ JE + +-[ Sub ]-+ 
[Network ] [Network ] 
|<---- DetNet MPLS ---->| 
EGELI DetNet IR i ia > 


Figure 1: Architecture: DetNet IP over DetNet MPLS Network 


4. DetNet IP over DetNet MPLS 


This section defines how IP-encapsulated flows are carried over a DetNet MPLS data plane as 
defined in [RFC8964]. Since both non-DetNet and DetNet IP packets are identical on the wire, this 
section is applicable to any node that supports IP over DetNet MPLS, and this section refers to 
both cases as DetNet IP over DetNet MPLS. 
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4.1. DetNet IP over DetNet MPLS Data Plane Scenarios 
An example use of DetNet IP over DetNet MPLS is presented here. 


Figure 1 illustrates IP DetNet-enabled End Systems (hosts) connected to DetNet-enabled IP 
networks (DN IP), operating over a DetNet-aware MPLS network. In this figure, we have a case 
where the relay nodes act as T-PEs and sit at the boundary of the MPLS domain since the non- 
MPLS domain is DetNet aware. This case is very similar to the DetNet MPLS Network (Figure 2 in 
[RFC8964]). However, in Figure 2 of [RFC8964], the T-PEs are located at the end system and MPLS 
spans the whole DetNet service. The primary difference in this document is that the relay nodes 
are at the edges of the MPLS domain and therefore function as T-PEs, and that MPLS service sub- 
layer functions are not provided over the DetNet IP network. The transit node functions shown 
above are identical to those described in [RFC8964]. 


Figure 2 illustrates how relay nodes can provide service protection over an MPLS domain. In this 
case, CE1 and CE2 are IP DetNet end systems that are interconnected via an MPLS domain such as 
that described in [RFC8964]. Note that R1 and R3 sit at the edges of an MPLS domain and therefore 
are similar to T-PEs, while R2 sits in the middle of the domain and is therefore similar to an S-PE. 


DetNet DetNet 
IP Service Transit Transit Service IP 
DetNet |<-Tnl->| |<-Tnl->| DetNet 
End | V 1 V V 2 V | End 
System | +======== + +======== + +======== + | System 
+---+ | | R1 |=======|] R2 |=======| R3 | | +---+ 
| [eee E ol PFG PEDER 
| CET | | | ae [es | | # | | |CE2 | 
l l | l Ya PEDERSD |e l l l 
iset | |======= | |======= | | poset 
A +-------- + +-------- + +-------- + A 
| Relay Node Relay Node Relay Node | 
| (T-PE) (S-PE) (T-PE) 
| | 
RSS IDS) aE eres Cai DetNet MPLS KE > <-DN IP->| 
| | 
[SRR RSS Sosa End to End DetNet Service --------------- > | 
SRS SSS Seo Datat [iO SSS SS 
X = Service protection (PRF, PREOF, PEF/POF) 
DFx = DetNet member flow x over a TE LSP 


Figure 2: Service Protection over DetNet MPLS Network for DetNet IP 


Figure 1 illustrates DetNet-enabled end systems connected to DetNet-enabled (DN) MPLS 
networks. A similar situation occurs when end systems are not DetNet aware. In this case, edge 
nodes sit at the boundary of the MPLS domain since it is also a DetNet domain boundary. The 
edge nodes provide DetNet service proxies for the end applications by initiating and terminating 
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DetNet service for the application's IP flows. While the node types differ, there is essentially no 
difference in data plane processing between relays and edges. There are likely to be differences in 
Controller Plane operation, particularly when distributed control plane protocols are used. 


It is still possible to provide DetNet service protection for non-DetNet-aware end systems. This 
case is basically the same as Figure 2, with the exception that CE1 and CE2 are non-DetNet-aware 
end systems and R1 and R3 become edge nodes. 


4.2. DetNet IP over DetNet MPLS Encapsulation 


The basic encapsulation approach is to treat a DetNet IP flow as an App-flow from the DetNet 
MPLS perspective. The corresponding example DetNet Sub-network format is shown in Figure 3. 


/-> +------ + +------ + +------ + AN 
| [EX | [EEX | | |<- App-flow 
| +------ + +------ + +------ + R. 
App-flow <-+ |NProto| |NProto| |NProto| (le) 
for MPLS | +------ + +------ + +------ + ae 
| | ae | | age | PERTE] V 
\-> +---+=2=====4+--+===2===+--+======+----- + 
DetNet-MPLS | d-CW | | d-CW | | d-CW | 
+------ + +------ + +------ + (2) 
|Labels| |Labels| |Labels| v 
+---+======+--+======4+--+======+-----— + 
Link/Sub-network LØ ee RR 
+------ + +------ + +------ + 
| EP 
+------ + 
pie | 
+------ + 


(1) DetNet IP Flow (or simply IP flow) 
(2) DetNet MPLS Flow 


Figure 3: Example DetNet IP over MPLS Sub-network Formats 


In Figure 3, "App-flow" indicates the payload carried by the DetNet IP data plane. "IP" and "NProto" 
indicate the fields described in Sections 5.1.1 (IP Header Information) and 5.1.2 (Other Protocol 
Header Information) of [RFC8939], respectively. "App-flow for MPLS" indicates that an individual 
DetNet IP flow is the payload from the perspective of the DetNet MPLS data plane defined in 
[RFC8964]. 


Per Section 5.1 of [RFC8964], the DetNet MPLS data plane uses a single S-Label to support a single 
App-flow. DetNet IP Flow Identification Procedures in Section 5.1 of [RFC8939] states that a single 
DetNet flow is identified based on IP- and next-level protocol header information. Section 4.4 of 
[RFC8939] (DetNet Flow Aggregation) defines the ways in which aggregation is supported through 
the use of prefixes, wildcards, lists, and port ranges. Collectively, this results in the fairly 
straightforward procedures defined in the next section. 
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As shown in Figure 2, DetNet relay nodes are responsible for the mapping of a DetNet flow, at the 
service sub-layer, from the IP to MPLS DetNet data planes and back again. Their related DetNet IP 
over DetNet MPLS data plane operation is comprised of two sets of procedures: the mapping of 
flow identifiers and ensuring proper traffic treatment. 


Mapping of IP to DetNet MPLS is similar for DetNet IP flows and IP flows. The six-tuple of IP is 
mapped to the S-Label in both cases. The various fields may be mapped or ignored when going 
from IP to MPLS. 


5. DetNet IP over DetNet MPLS Procedures 


The main differences of mapping IP to DetNet MPLS (compared to plain MPLS) are that (1) there 
is a mandatory flow identification to make the forwarding decision (i.e., forwarding is not based 
on FEC), (2) the d-CW (DetNet Control Word) is mandatory for the MPLS encapsulation, and (3) 
during forwarding over the DetNet MPLS network, treatment specific to DetNet flows is needed. 


5.1. DetNet IP over DetNet MPLS Flow Identification and Aggregation 
Procedures 


A DetNet relay node (ingress T-PE) that sends a DetNet IP flow over a DetNet MPLS network MUST 
map a DetNet IP flow, as identified in [RFC8939], into a single MPLS DetNet flow and MUST process 
it in accordance to the procedures defined in [RFC8964]. PRF MAY be supported at the MPLS level 
for DetNet IP flows sent over a DetNet MPLS network. Aggregation MAY be supported as defined in 
Section 4.4 of [RFC8964]. Aggregation considerations in [RFC8939] MAY be used to identify an 
individual DetNet IP flow. The provisioning of the mapping of DetNet IP flows to DetNet MPLS 
flows MUST be supported via configuration, e.g., via the Controller Plane. 


A DetNet relay node (egress T-PE) MAY be provisioned to handle packets received via the DetNet 
MPLS data plane as DetNet IP flows. A single incoming DetNet MPLS flow MAY be treated as a 
single DetNet IP flow, without examination of IP headers. Alternatively, packets received via the 
DetNet MPLS data plane MAY follow the normal DetNet IP flow identification procedures defined 
in Section 5.1 of [RFC8939]. 


An implementation MUST support the provisioning for handling any packet flows received via the 
DetNet MPLS data plane as DetNet IP flows via configuration. Note that such configuration MAY 
include support from PREOF on the incoming DetNet MPLS flow. 


Note: Using Layer 4 (L4) transport protocols (e.g., for multipath) are out of scope of 
this document both for a single flow and aggregate flows. 


5.2. DetNet IP over DetNet MPLS Traffic Treatment Procedures 


The traffic treatment required for a particular DetNet IP flow is provisioned via configuration or 
the Controller Plane. When a DetNet IP flow is sent over DetNet MPLS, a DetNet relay node MUST 
ensure that the provisioned DetNet IP traffic treatment is provided at the forwarding sub-layer as 
described in Section 5.2 of [RFC8964]. Note that PRF MAY be utilized when sending IP over MPLS. 
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Traffic treatment for DetNet IP flows received over the DetNet MPLS data plane MUST follow 
Section 5.3 of [RFC8939] (DetNet IP Traffic Treatment Procedures). 


6. Management and Control Information Summary 


The following summarizes the set of information that is needed to support DetNet IP over DetNet 
MPLS at the MPLS ingress node: 


e Each MPLS App-Flow is selected from the incoming IP traffic using the IP flow identification 
information defined in [RFC8939]. This information is summarized in Section 5.1 of that 
document and includes all wildcards, port ranges, and the ability to ignore specific IP fields. 

e The DetNet MPLS service that is to be used to send the matching IP traffic. This matching 
information is provided in Section 5.1 of [RFC8964] and includes both service and traffic 
delivery information. 


The following summarizes the set of information that is needed to support DetNet IP over DetNet 
MPLS at the MPLS egress node: 


° The S-Label value that identifies the encapsulated App-flow traffic. 

e For each S-Label, how the received traffic is to be handled. The traffic may be processed as any 
other DetNet IP traffic as defined in this document or in [RFC8939], or the traffic may be 
directly treated as an MPLS App-flow for additional processing according to [RFC8964]. 


It is the responsibility of the DetNet Controller Plane to properly provision both flow 
identification information and the flow-specific resources needed to provide the traffic treatment 
to meet each flow's service requirements. This applies for aggregated and individual flows. 


7. Security Considerations 


General security considerations for DetNet are described in detail in [RFC9055]. DetNet MPLS and 
DetNet IP security considerations equally apply to this document and are described in [RFC8964] 
and [RFC8939]. 


Security aspects that are unique to DetNet are those whose aim is to protect the support of specific 
quality-of-service aspects of DetNet, which are primarily to deliver data flows with extremely low 
packet loss rates and bounded end-to-end delivery latency. 


The primary considerations for the data plane are to maintain integrity of data and delivery of 
the associated DetNet service traversing the DetNet network. Application flows can be protected 
through whatever means is provided by the underlying technology. For example, encryption may 
be used, such as that provided by IPsec [RFC4301] for IP flows and/or by an underlying sub-net 
using MACsec [IEEE802.1AE-2018] for IP-over-Ethernet (Layer 2) flows. 


From a data plane perspective, this document does not add or modify any header information. 
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At the management and control level, DetNet flows are identified on a per-flow basis, which may 
provide Controller Plane attackers with additional information about the data flows (when 
compared to Controller Planes that do not include per-flow identification). This is an inherent 
property of DetNet, which has security implications that should be considered when determining 
if DetNet is a suitable technology for any given use case. 


To provide uninterrupted availability of the DetNet service, provisions can be made against DoS 
attacks and delay attacks. To protect against DoS attacks, excess traffic due to malicious or 
malfunctioning devices can be prevented or mitigated, for example, through the use of existing 
mechanisms such as policing and shaping applied at the input of a DetNet domain. To prevent 
DetNet packets from being delayed by an entity external to a DetNet domain, DetNet technology 
definitions can allow for the mitigation of man-in-the-middle attacks (for example, through use 
of authentication and authorization of devices within the DetNet domain). 


8. IANA Considerations 


This document has no IANA actions. 
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